In the Third Generation Partnership Project (3GPP), multicast and broadcast is introduced in a work item referred to as Multimedia Broadcast/Multicast Service (MBMS). FIG. 1 is a simplified block diagram illustrating the current MBMS architecture, as defined in the stage 2 specification. The architecture utilizes network nodes from the General Packet Radio Service (GPRS) radio network.
With Digital Rights Management (DRM), the content is possibly encrypted and accompanied by a rights object. The rights object specifies what the user is allowed to do with the content. A basic concept with DRM is that charging/payment is based on the rights object and not on the content object since the value does not lie in the (possibly encrypted) content any longer, but in the rights to (possibly decrypt and) use the content.
From a content provider, a protected content object may be sent to a User Equipment (UE) mobile client through a Wireless Local Area Network (WLAN), or any other circuit-switched or packet-switched access network, including the Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), or a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN). Meanwhile, the rights object may be sent from the content provider on a separate path through a Rights Server and a different Gateway GPRS Support Node (GGSN) and Serving GPRS Support Node (SGSN) before reaching the UTRAN and the mobile client. Thus, there is a potential distribution time and path difference between the content and the rights.
Anycast is an Internet network service that allows a sender to access the nearest of a group of receivers that share the same anycast address, where ‘nearest’ is defined according to the routing system's measure of distance. Anycasting is like multicasting in that the destination is a group of addresses, but instead of trying to deliver the packet to all of the members of the group, the network tries to deliver the message to only the nearest member. The source is not required to pick the closest destination, because the routing system figures it out. Usually the receivers in the anycast group are replicas, able to support the same service (for example, mirrored web servers). Thus, accessing the nearest receiver enhances the performance perceived by the sender, saves the network's bandwidth, and provides the desired service.
In IPv6, special anycast addresses have been specified in addition to the unicast and multicast addresses. An anycast address identifies a set of interfaces that typically belong to different nodes. A packet sent to an anycast address is delivered to the “nearest” interface identified by that address, according to the routing protocol's measure of distance. Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address. Anycast addresses are only assigned to IPv6 routers, not to IPv6 hosts.
To join an anycast group, a host asks its first hop router to advertise the group's address on its behalf This communication may be achieved by adding a new message type to either the Internet Group Management Protocol (IGMP) or the Neighbor Discovery Protocol. The router then advertises the address according to the anycast routing protocol adopted by the domain.
In 3G wireless networks, users can register to an anycast group on the application level. This can be done by means of registration messages such as available in IGMP or the Multicast Listener Discovery Protocol (MLD). However, since each UE is only one IP hop away from the GGSN, there is currently no means for the GGSN to distinguish between different anycast group members in the same Public Land Mobile Network (PLMN). In case of large PLMNs the distance between the GGSN and the anycast members may vary significantly. This is especially valid in case of anycast on the Gp interface (i.e. between a GGSN and SGSN in different PLMNs). Thus, efficient anycasting is not currently supported in the PLMN. In case of multiple hosts in the anycast group in the PLMN, the GGSN must simply apply a round robin algorithm to select one of the clients. Therefore, the closest host is not always selected.
Mobile networks currently do not enable mobile clients to act as a distributed content cache and to redistribute the content to other clients. Data caching and distribution is, to a large extent, centrally controlled by a server in the network. Because of this limitation, content providers and/or network operators must either accept the fact that they cannot guarantee that multicast or broadcast clients can always retrieve the content, or they must provide other means for providing guaranteed delivery and retrieval. For example, they may utilize cyclic repeating, or add additional network resources such as additional caches in the network to guarantee that the data is not lost. These resources store the content itself, or store links to the content provider, in order for the client to retrieve the content from the content provider. In the latter case, the content retrieval path is longer and thus more expensive for the content provider, the network operator, and inherently also for the end-user.